This invention generally relates to execute in place (XIP) architectures within electronic devices and, more particularly, to an extensible XIP architecture and related methods.
The concept of an execute in place (XIP) architecture is not new. Simplistically, an XIP architecture is defined by a system""s ability to execute one or more bytes of code while still resident within non-volatile memory (e.g., read-only memory (ROM)), without first transferring the code to volatile memory (e.g., random access memory (RAM)). An XIP architecture is typically comprised of an image having a plurality of modules, stored across one or more non-volatile memory devices. The modules within an image represent applications, dynamic link libraries, data, and the like. In this regard, an image represents a snapshot of a system""s operational capability at a point in time. An example of a simple XIP architecture is presented with reference to FIG. 1.
FIG. 1 illustrates a block diagram of computing system 100 utilizing a typical prior art XIP architecture. Computing system 100 is shown comprising a processor 102, coupled to system memory 104 via bus 106. System memory 104 is comprised of volatile memory (e.g., random access memory, or RAM) 108 and non-volatile memory (e.g., read-only memory, or ROM) 110. In addition, computer 100 may include one or more of input device(s) 112, input/output (I/O) interface(s), or ports 114 and a display device 116, each coupled as shown.
As introduced above, computing system 100 includes XIP capability, i.e., the ability to access and/or execute one or more objects (applications, data files, DLL""s, etc.) from the non-volatile memory 110. An advantage of XIP architectures such as the one depicted in FIG. 1 is that executing code directly from non-volatile memory 110 reduces the amount of expensive volatile memory 108 required, thereby reducing the overall cost of the system. Moreover, by executing code directly from the non-volatile memory, the perceived execution time of code is faster in a XIP architecture than for a non-XIP architecture. Consequently, XIP architectures are often utilized within personal digital assistants, embedded systems, communications devices (e.g., cellular telephones), information appliances, and other cost sensitive, consumer appliances.
While the cost and performance attributes of the XIP architecture are enticing, the XIP architecture is not without its limitations. One limitation of prior art XIP architectures is that there can be only one (1) XIP region, i.e., region of non-volatile memory that supports XIP. This represents a fundamental limitation of prior art XIP architectures in that the entire XIP image must be replaced to update any of the objects contained therein.
That is, a limitation commonly associated with prior art XIP architectures is the inability to cohesively upgrade individual objects within the XIP architecture without replacing the entire image, or losing the XIP capability. A prior art solution to overcoming this limitation is to embed the new/updated object(s) on an accessible PCMCIA card. This, however, does not preserve the true XIP capability as the objects must be copied from the PCMCIA card to volatile memory 108 for execution.
It will be appreciated by those skilled in the art that replacing the entire image requires replacing of the physical non-volatile memory modules within the devicexe2x80x94a task that typically requires the assistance of a skilled technician. Thus, while the initial cost advantages of prior art XIP architectures appear attractive, the inability to selectively modify image components often renders the lifetime cost of such systems prohibitively expensive.
Thus, what is required as an extensible XIP architecture unencumbered by the limitations commonly associated with prior art XIP architectures. Just such a system is presented in the disclosure to follow.
This invention concerns an extensible execute-in-place (XIP) architecture and related methods for supporting multiple XIP regions. In accordance with a first example embodiment, a system implementing an execute-in-place (XIP) architecture is presented comprising a plurality of XIP regions. To facilitate execute-in-place functionality across the multiple XIP regions, a virtual address table (VAT) is generated to store pointers to the objects stored in the non-volatile memory hosting the multiple XIP regions.